"Transaction Processing" 

INTRODUCTION 

5 Field of the Invention 

The invention relates to real time authorisation of transactions using non-cash payment 
instruments such as credit cards and debit cards. 

10 Prior Art Discussion 

While there has been much discussion in recent years concerning card-not-present (and 
particularly Internet shopping) fraud, in fact the bulk of credit card fraud arises from 
card-present transactions. For example, card "skimming" often results in a fraudulent 
15 card being produced and used, possibly in a different country from where the skimming 
occurred. Another example is mail interception, in which cards are stolen from the postal 
system as they are en route to the customer. 

While the losses arising from fraud are very considerable, efforts to date at providing new 
20 systems to reduce fraud have met with only limited success. In one approach marketed 
by the company Orbiscom™ a "disposable" card number is issued to which limited use 
conditions are applied. This approach appears to be of benefit for Internet transactions, 
however it is generally believed to be of little benefit for card present transactions. 

25 In another approach, "neural intelligence" is used by the issuer to monitor proposed 
transactions and to block those which do not appear to fit a usage pattern for the 
cardholders. These systems monitor patterns of usage and on the basis of this 
monitoring, determine when usage is out of the ordinary. While this appears to be a very 
helpful approach, it suffers from practical problems. For example, a cardholder may find 

30 to his or her embarrassment and inconvenience that he or she can not use a card when on 
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holiday in a foreign country. The overall impression the cardholder has is that he or she 
is not in control and does not understand how his or her transactions are controlled. 

The invention is therefore directed towards providing a system and method for real time 
5 processing of transactions to reduce overall fraud. Another object is to help ensure that 
cardholders are more in control of how their cards are used and that they are informed of 
what is happening. 

SUMMARY OF THE INVENTION 

10 

According to the invention, there is provided a transaction processing system 
comprising an interface for receiving authorisation requests, an interface for transmitting 
authorisation outputs, and a processing means comprising means for determining from 
authorisation request data if the system output should be positive for negative, 
15 characterised in that the processing means comprises: 

a setup means comprising means for storing transaction conditions 
associated with particular customers, and 

20 authorisation means for dynamically retrieving a transaction condition 

associated with the customer of each authorisation request on a per- 
transaction basis and for applying said conditions to the authorisation 
request. 

25 In one embodiment the setup means comprises an interface comprising means for 
allowing each customer to define said conditions. 



In one embodiment said interface comprises a Web server. 



In another embodiment the setup means comprises means for storing predefined template 
conditions, and for allowing a customer to select predefined template conditions for his or 
her card. 

In a further embodiment the setup means comprises a fraud manager interface comprising 
means for allowing a fraud manager with access control to define said template 
conditions. 

In one embodiment the predefined template condition comprises specific placeholders for 
conditions, values and logical operators. 

In one embodiment the setup means comprises input means for allowing a customer to 
input customer specified parameters to the predefined template conditions. 

In another embodiment each template comprises an associated action which is the action 
to be taken if, upon evaluation, the template condition evaluates to "true". 

In a further embodiment at least some of the conditions are in the form of program code 
rules. 

In one embodiment the setup means comprises means for maintaining a rule database. 

In one embodiment the rule database comprises means for storing rules in a format which 
is indexed on a particular customer or customer card number. 

In another embodiment said rules comprise system, product and customer rules. 

In one embodiment said rules are stored in a format which does not require parsing of 
logical string-based expressions for processing. 
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In one embodiment the authorisation means comprises means for automatically 
transmitting a notification to a customer under control of the conditions. 

In another embodiment the authorisation means comprises means for receiving 
5 confirmation of authorisation from a customer in response to a notification. 

In a further embodiment the authorisation means comprises means for successively 
applying system-level, card product-level, and the customer conditions upon receipt of an 
authorisation request. 

10 

In another embodiment the authorisation request interface comprises a network interface 
for interfacing with a card payment network. 

In one embodiment the authorisation request interface comprises a network interface for 
15 interfacing with an issuer front end system. 

In one embodiment the output interface further comprises a card management system 
interface means for interfacing with an issuer card management system. 

20 In one embodiment the network interface comprises means for communicating over 
TCP/IP, X.25, Serial, Modem, SNA or any other communication format. 

In a further embodiment the network interface comprises for converting received 
messages into a general standard data format 

25 

In another embodiment the network interface comprises a communication header module 
for converting received messages into a standardised data sequence of bytes. 
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In one embodiment the card management system interface comprises a protocol header 
module comprising means for converting a standardised sequence of bytes received from 
the network interface into an internal format for processing. 

5 In another embodiment the card management system interface comprises a protocol 
header module comprising means for converting a standardised sequence of bytes 
received from a communications header module into an internal format for processing. 

c 

In a further embodiment the communication header and the protocol header modules 
10 comprise means for sequentially checking for, receiving, converting and routing 
messages and data. 

In one embodiment the communication header and protocol header modules comprise 
means for routing transaction requests and responses between the card payment network 
1 5 and card management system. 

In one embodiment the authorisation means comprises means for updating the rules 
database in real time. 

20 In another embodiment the authorisation means comprises means for automatically 
transmitting a notification to a fraud manager if a possible fraud is detected. 

In a further embodiment the setup means comprises means for automatically transmitting 
a notification to a customer if a possible fraud is detected. 

25 

In one embodiment the authorisation means comprises means for automatically 
transmitting a notification to a customer if an authorisation request is rejected. 
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In another embodiment the authorisation means comprises means for automatically 
transmitting a notification to a customer if a request is authorised, allowing a customer to 
maintain a local log of authorised requests. 

5 In a further embodiment the setup means comprises means for controlling customer 
activation of a card. 

In one embodiment said controlling means comprises an on-line banking interface. 

10 In another embodiment said controlling means comprises an ATM interface. 

In a further embodiment the authorisation means comprises means for receiving a 
cardholder request that a card be deactivated. 

15 In one embodiment said means comprises means for receiving an SMS from a 
cardholder. 

According to another aspect of the invention, there is provided A transaction 
processing method carried by a verification system, and comprising the steps of: 

20 

(i) receiving a transaction condition associated with a customer ; 

(ii) writing said condition to a condition database also storing conditions 
associated with other customers; 

25 

(iii) receiving a transaction authorisation request from a transaction network; 

(iv) processing said received authorisation request by dynamically retrieving a 
condition associated with the customer of the authorisation request on a per 

30 transaction basis; 
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(v) applying said condition and determining from the authorisation request data if 
the requested transaction should be approved or denied. 

5 DETAILED DESCRIPTION OF THE INVENTION 

Brief Description of the Drawings 

The invention will be more clearly understood from the following description of some 
10 embodiments thereof, given by way of example only with reference to the accompanying 
drawings in which:- 

Fig. 1 is a flow diagram illustrating signal transfers for transaction processing of the 
invention; 

15 

Figs. 2(a), 2(b) and 2(c) are block diagrams illustrating alternative arrangements for 
connecting the components of a verification system of the invention; 

Fig. 3 is a diagram showing interaction between a front end system and a card 
20 management system; 

Figs. 4, 5, and 6 are flow diagrams showing signalling at a lower level; 

Fig. 7 is a flow diagram illustrating processing steps in more detail; 
25 - 

Fig. 8 is a diagram illustrating a database object containing templates and cardholder 
rules; 

Figs. 9 to 13 are diagrams illustrating interactions between a fraud manager and a rule 
30 database; 



Figs. 14 and 15 are diagrams showing interactions between a fraud manager and a Web 
server; 

Figs. 16 to 27 are diagrams showing interaction between people of various roles and 
systems of the invention; and 

Figs. 28, 29, and 30 are sample screen shots for system displays. 
Description of the Embodiments 

Referring to Fig. 1, in overview, in a step A a cardholder system 1 accesses a banking 
interface 2 via the Internet, although it may alternatively be via wireless device, 
telephone or branch visit. The banking interface 2 is operated by an issuing bank of 
which the cardholder is a customer. The interface 2 is connected to an issuing system 3, 
in turn connected to a verification system 4. The interface 2 allows the cardholder to 
input rules governing how credit card transactions with her card are to be authorised. 
These rules can be set according to a wide variety of parameters such as:- 

• deny if merchant is located outside of Ireland, 

• deny if the transaction amount exceeds EUR300, or 

• notify me by SMS for every transaction greater than EUR1 00. 

The rules are updated to the verification system in a step B, and are maintained in a rule 
database. They can be dynamically varied by the cardholder or by issuer personnel such 
as a fraud manager. 

In a step C the cardholder initiates a purchase transaction with her card, the transaction 
being handled by a merchant system 5. In a step D the merchant system 5 forwards the 
transaction details to an acquiring system 6, which in step E forwards an authorisation 
request to a card network device 7. In a step F the verification system 4 executes the 
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rules created by the cardholder in order to pass on or deny the transaction. If passed on, 
the issuing system 3 is updated in a step G, otherwise a deny signal is transmitted in a 
step H. 

5 It will be appreciated that the systems and method allow the cardholder to be involved in 
the overall authorisation cycle so that usage control is tailored to his or her requirements. 

This opens up other services in addition to effective fraud control. For example, a rule 
may require for an SMS notification to be forwarded to a parent every time a card is used. 
10 This allows parents to continually monitor and track usage for parental control and 
information purposes. In effect, suitable rules can cause a full audit trail to be generated 
in real time, when the information is required and is of most benefit. 

We shall refer to the sequence of Fig. 1 as being the 'authorisation chain 1 . It can be 
15 described as a chain because it consists of the Merchant requesting an authorisation from 
an Acquirer; an Acquirer requesting an authorisation from the network and the network 
requesting authorisation from the Issuer. 

This invention inserts into this chain a device whose function is to implement Cardholder 
20 authorisation rules. This device is located at an Issuer's premises or at a remote location 
and is connected to the Issuer's systems using secure communication means. 

Figs. 2(a), 2(b) and 2(c) show three alternative arrangements for integrating the 
verification system into an authorisation system. The main components are the 
25 verification system (also referred to as the rule processor) 4, the card management 
(Issuer) system (CMS) 3, and optionally a front end system (FES) 10. 



30 



The function of the rule processor 4 is to decide whether a particular request should be 
passed on to the issuer or declined based on the processing of system, product and 
cardholder rules. The rule processor makes this decision by evaluating rules on the 
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authorisation request. These rules are read in from a rule database. Three types of rules 
can be entered into the rule database: 

• Rules that must be evaluated on every authorisation request - 'System Rules 1 

• Rules that must be evaluated on authorisation requests that relate to payment cards 
5 that form part of a particular product ("Product Rules"). 

• Rules that must be evaluated on authorisation requests that are for particular payment 
cards - 'Cardholder Rules'. 

The CMS 3 is the terminal device in the authorisation chain. Authorisation request 
10 responses are generated by this device. The FES 10 interfaces with the card payment 
network and receives authorisation requests. The rule processor 4 further comprises an 
SMS/Email gateway 19 which allows email SMS, EMS, MMS or any other 
communication format messages to be sent to the cardholders or received from the 
cardholders. 

15 

Referring to Figs. 2(a) the rule processor 4 is connected between the FES 10 and the 
CMS 3. The corresponding Fig. 3 illustrates the flow of requests in this embodiment. In 
the normal mode of operation, an authorisation request received from the card payment 
network moves from the FES 10 and into the rule processor 4. The rule processor decides 
20 whether the authorisation request is sent on to the CMS 3, or whether an authorisation 
request response - a decline - is sent back to the network side device. The system also 
supports a bypass mode of operation used by default if a malfunction or failure is 
detected in the rule processor. In the bypass mode requests are routed directly from the 
FES to the CMS. 

25 

Referring to Fig. 2(b), in another embodiment the rule processor 4 is interfaced to the 
FES 10. In operation, authorisation requests from the card payment network received by 
the FES 10 are routed to the rule processor 4. The rule processor applies rules to the 
requests and sends them back into the FES which decides whether or not to route them to 
30 the CMS 3. 
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Referring to Fig. 2(c), in another embodiment authorisation requests are accepted from 
the card payment network into the rule processor 4, where rules are applied to the 
requests. The rule processor then routes permitted authorisation requests to the CMS 3. 

5 

The verification system (or rule processor) of the present invention is designed to 
integrate flexibly into existing card management (Issuer) systems. While it is possible to 
include additional functionality by adding more features to a particular 'card management 
system' because each card management system is different such an approach is 
10 problematic. The verification system is designed to be placed in the authorisation chain 
as a separate entity witiiin that chain. However, in order to integrate the verification 
system into existing card management systems significant communications issues must 
be addressed. 

15 Figs. 4 to 6 illustrate the communication modules and routing processes of the invention. 

IS08583 is used over many different types of communications media, depending on the 
equipment that is being used and the preferences of the institutions involved. These 
media include: . 

20 

TCP/IP 

X.25 

SNA 

Serial Line 
25 Modem 

Messages that are sent between entities involved in the authorisation process are 
standardised according to the IS08583 standard - "Bank card originated messages - 
Interchange message specifications - Content for financial transactions'. To facilitate 
30 connection and integration of the verification system of the invention into an existing 
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authorisation chain a module which converts messages from any particular medium into a 
"stream of bytes" is used. This module is a CH (Communications Header). 

Referring to Fig. 4 an IS08583 Message is read by a CH (Communications Header) from 
5 whatever form of communications channel the incoming messages are arriving on. The 
message is converted into a sequence of bytes and passed to a PH (Protocol Header) 
module. The CH is a module that sends and receives data without regard to the content. 
It understands and implements the specifics needed to handle connections over different 
media - e.g. TCP/IP, X.25, Serial and Modem. It provides common functions for the set- 
10 up, management and teardown of open connections. The PH layer converts the message 
from a specific 8583-message implementation into an internal 'Normalised' form. This 
form is independent of any vendor specific implementations. 

After being processed by a Test Rules' process of the rule processor (described later) the 
15 message is converted from the 'Normalised' form back into a specific 8583 
implementation via the PH layer, and then is sent to its destination via the CH layer. 

Referring to Fig. 5 the CH connects to its PH module. It then attempts to connect to its 
8583 source using the specified method (TCP/IP, X.25 or Serial). It then checks whether 
20 there are any bytes ready to be accepted from the PH module. If there are no bytes 
available it immediately checks whether there are any available from the 8583 source. If 
there are none, it immediately goes back to check whether there are any bytes available 
from the PH and proceeds as before. 

25 If there are bytes available from the PH, they are read, and sent to the 8583 source, and 
then checks are made for bytes being available from 8583 source and PH as before. 

If there are bytes available from the 8583 source, they are read, and sent to the PH, and 
then checks are made for bytes being available from the PH and the 8583 source as 
30 before. 



-13- 

IS08583 is a standard that describes the messaging that is used to allow organisations to 
exchange messages that relate to 'Bank Cards'. This specification although complete in 
many ways is interpreted differently by different organisations. The differences relate for 
5 example to the specific meaning of a field, or the choice of field to hold a particular piece 
of data or how a particular response is to be interpreted. For the invention, the 
implication of this problem is that a message from one source may differ significantly 
from a message from another source, not because of any difference in the core transaction 
details, but because of differences between the organisations that are feeding the 
10 transactions into the verification system. 

Because of this, a technique is presented for converting many known implementations of 
IS08583 into a single generalised format. Examples of 8583 protocol implementations 
include: 

15 



Vendor Implementation Description 


VISA BASE I 


Visa Credit Card implementation 


MasterCard CIS 


MasterCard Credit Card implementation 


BASE 24 Host ISO 


ACI Credit Card implementation 


Europay Host EM 


MasterCard Credit & Debit Card implementation 


VISA SMS 


Visa Debit Card implementation 


MasterCard MDS 


MasterCard Debit Card implementation 



Referring to Fig. 6 the PH initially connects to a Test Rules' process of the rule 
processor. It then connects to the CH. It checks whether there are any bytes available 
20 from the CH. If there are not, it immediately checks whether there are any messages 
available from the Application Process. If there are none, it goes back to check for bytes 
from the CH and so on. 
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If there are bytes available from the CH, they are read and converted into a message. At 
this stage, the message is in the format of a vendor specific implementation of IS08583. 
This message is then converted into a normalised form using transformations that are 
specific to this specific PH. These transformations are very much related to each vendor's 
5 implementation and thus can be arbitrarily complicated. For example, a particular field 
may be broken down in a particular manner by a vendor implementation. 

After the normalised message is generated, it is sent to the application process. The PH 
then goes back to checking for bytes from the CH. 

10 

If a message is available from an application, it is read and converted to de-normalised 
form using PH transformations. It is then converted into a sequence of bytes and passed 
to the CH. The PH then goes back to checking for bytes from the CH. 

15 Referring to Fig, 7 the authorisation cycle or "Test Rules" process of the rule processor is 
shown in more detail. The request is generated in step 101. If the number prefix is that 
of a valid product (step 102) in step 104 system rules are applied. If the output is 
negative in step 113 a decline response is generated. Otherwise, in step 105 product rules 
are applied. If the output is negative, again a decline response is generated. Otherwise, 

20 the Cardholder rules are applied in step 106. Again, this may provide a positive or a 
negative outcome. 

The three possible outcomes of application of the sequence of three sets of rules are: 
decline, 

25 approve and pass to CMS, and 

create fraud queue item. 

The third outcome causes an item to be added to a fraud queue. In this embodiment, a 
decline outcome may cause a message to be sent to the Cardholder (steps 116, 117, 118). 



-15- 



Process Messages According to Defined Rules 

The Cardholder can communicate through the Issuer's computer system. The Cardholder 
communicates with the Issuer's computer system through whatever means the Issuer's 
5 computer system supports - e.g. Internet, phone, WAP. By doing this, the Cardholder 
can enter a set of rules. A rule may be in the form of 
IF (Condition) THEN (Action) 

Each Condition can be a set of comparisons separated by AND and OR. Each 
10 comparison compares a authorisation request data element with a value. An example of a 
condition would be: 

Amount > "100.00" AND (MerchantCountry = "IE" OR MerchantCountry ="UK") 

This example condition would apply whenever the transaction amount is greater than 100 
15 and the Merchant is registered in Ireland or the UK. 

Each action is one of three choices - either 'decline 1 or 'accept' or 'advise Fraud 
Manager or advise Cardholder in the event of an automatic confirmation system being 
implemented'. The term 'decline* means to not send the request onwards to the CMS, but 
20 to send an authorisation rejection back towards the Acquirer. The term 'accept' means to 
send the authorisation request on towards the Issuer. The term 'advise Fraud Manager' 
means to send a message to a Fraud Manager about the authorisation. 

In addition to cardholder rules, the Fraud Manager in the issuing institution can also enter 
25 rules. These rules can be entered at three levels. The first of these is the set of rules that 
are run for every transaction that passes through the system - these are termed 'system' 
rules. The second of these is the set of rules that are run for each 'product' that the 
issuing institution markets. A product in this sense is a set of credit card number ranges 
that are grouped together. The third of these is the set of 'template rules' for a particular 
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product. These are pre-written rules that a Cardholder who has a card from particular 
product can 'opt into' without having to write the rule themselves. 

The invention allows complex rules to be built and enables them to be executed in a very 
5 time-efficient manner by using template rules. 



10 



Each template is built in response to Fraud Manager inputs by the Fraud Manager and is 
given an index number (#1, #2, ..). Each template comprises a set of empty placeholders 
for up to ten conditions. Each condition comprises the following: 



Template index Number 
Field Number 

Condition 



Value 

Logical Operator 



Unique identifier for this template. 
Number of field in message 
Eg Tield32 could be Merchant Country' 
Condition to apply to field 
Eg - 'equals'/ 'does not equal* / 'is less than* / 'is 
greater than* 

- Value to compare against 

- Operator to use with next condition 
Eg -'AND' /'OR' 



Also associated with each template is an 'Action 5 . This is the action to take if the 
condition evaluates to 'True 1 . Each action is composed of the following elements: 



Event 



Direction 



Response Code 



- Event that should take place 

Eg - 'Decline' / 'Approve' / 'Advise' 

- Direction to send message 
Eg- 'Forward' /'Back' 

- Value to set in 'Response Code' field of message. 
Eg - '01 - refer to Card Issuer' 
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Each template also includes 'Notification' fields. These fields indicate whether an Email 
or SMS notification should be sent if the condition above evaluates to 'True'. 

Cardholder Rules 

5 Each cardholder rule comprises a reference to a template and any information required by 
that template. Accordingly, the fields involved are: 

Card Number -The unique number of the card 

Template -The number of the template to which this rule refers. 

Parameterl -If any conditions for this template require a parameter 



All of the cardholder rules in the system are stored in the system database and are 
10 indexed and clustered on card number. 

Real Time - not Batch 

The invention allows Cardholders and Fraud Managers to view and modify rules while, at 
the same time, processing authorisation transactions using these rules. Updates to the 
15 rules can be made in real time with the effect of such a change being immediate. 

In order to allow this to occur, 'database transactions' are defined for the purposes of 
reading and updating the table in which rules are stored. The purpose of these 
transactions is to allow updates to rules to occur in the moments between one 
20 authorisation transaction and the next. 



Email Address 



Sequence 



Parameter2 



SMS Address 



(eg Template condition is 'Amount >= User_Specified_Amount), 
the first of these parameters is stored here. 
-As Parameterl above. 
-SMS Address of this cardholder if required. 
-Email Address of this cardholder if required. 
-Sequence in which the rules associated with this cardholder should 
be executed. 
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Processing Efficiency 

The processing efficiency of the system is based upon the time taken to read all rules 
related to a particular card out of the database and the time taken to computationally 
5 apply the rules to the transaction in hand. 

By having cardholder rules refer to templates rather than exist in a stand-alone manner 
makes each cardholder rule very small (<100 bytes). This means that a minimal amount 
of disk space will be used per rule, and so more rules can be read per database read. 

By clustering the cardholder rules within the database on Card Number, ail rules related 
to a particular Cardholder can be read in one disk read by the database. 

By allowing templates to have specific placeholders for conditions, values and logical 
15 operators there is no requirement for the normal parsing of logical string-based 
expressions. Processing can proceed without the need for intensive string parsing. 

Referring to Fig. 8, an example of a database object containing two templates and two 
sets of Cardholder rules is illustrated. 

20 < 

Template #1 contains the rule: 

IF (Field32=' Africa' OR Field32=' Asia' OR Field32='Australia') 
THEN 

Sent Decline Back with Response Code 2 
Send SMS and Email to Cardholder 

25 Template #2 contains the rule: 

IF (Field41.2='20' OR Field41.2='20) 
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THEN 

Send Decline Back with Response Code 2 



Cardholder Rules for card '1234123412341234': 

IF (Card Number is ' 12341234123412340 
5 Apply Template 1 with no parameters, 

and SMS Address 0872337868 
and Email Address joebioggs@aol.com 

Apply Template 2 with no parameters, 
and no SMS Address 
1 0 and no Email Address 



Cardholder Rules for card '9999999999999999': 

IF (Card Number is '9999999999999999') 
15 Apply Template 1 with no parameters, 

and SMS Address 0872337868 
andEmailAddressjoebloggs@aol.com 

Figs. 9 to 25 illustrate how Issuer Personnel and Cardholders interact with the rule 
20 processor. 



Users of the system are as follows: 



User 


Role 


Cardholder 


The Cardholder is a person who holds a credit card, which has been issued by 
the Issuer. The invention primarily allows the Cardholder to add rules that 
control how his/her card is used. 


Fraud 


The Fraud Manager is an employee of the Issuer. The invention allows this 
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Manager 


person to add rules to particular control how particular credit card products 
operate. This can be done in order to reduce Fraud, or in order to create new 
types of credit card products with different operating profiles. 


CSR 


The Customer Service Representatives answer queries from Cardholders. The 
invention allows CSRs to perform all of the tasks that a Cardholder can 
perform. Also, the CSR is able to view details on the authorisation requests 
and responses for particular cards over given time periods. 


Technical 
Operator 


The Technical Operator is responsible for starting and stopping the system, 
editing database data, applying new configuration data to the system and 
checking the status of the system. 


Auditor 


The Auditor's is allowed see, at a great level of detail the decisions being 
made by the system, and is able to trace these decisions back to individual 
messages and rules. 



The Fraud Manager is that person in the Issuing Institution whose function is to track and 
minimise the incidence of fraud in the institution. This person and the Cardholder are die 
prime users of the system 4. The Fraud Manager configures the system 4 according to 
5 the needs of the Issuer. Figs. 9 to 15 illustrate some interactions of the Fraud Manager 
with the system. 



Fraud Manager adds or modifies products (Fig. 9) 

The Fraud Manager must define those products that the Issuer uses. A product is a set of 
10 credit cards that a Fraud Manager wishes to view as a single entity for the purpose of 
applying rules to them. These may in fact be individual products that the Issuer offers its 
customers (e.g. Standard Card, Gold Card, Platinum Card,) or they may be collections or 
subsets of same. 

15 Fraud Manager adds or modifies BIN (Fig. 10) 

Each Issuer has a set of allocated credit card number prefixes (Bank Identifier Numbers 
or 'BIN's). In the natural course of events, it divides these up between the products that it 
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creates. For instance, it might create a student credit card product, a normal credit card 
product and a gold credit card product. These products, and their associated BIN's are 
entered into the system as part of the product definitions. 

Fraud Manager modifies system or product or template rules (Fig. 11) 
The Fraud Manager can add rules to the system 4 of types 'System', . 'Product' or 
'Template'. Rules lie at the core of the system 4 and are in three types. Each rule type is 
applied in the following order to each authorisation request message: 

• System Rules are applied to all messages arriving from the network. 

• Product Rules are applied to all messages in particular BIN ranges arriving from 
Network. 

• Cardholder rules are applied to all messages that relate to a particular credit card 
number. A Cardholder rule can be created in one of two ways: 

• It can be created by the Fraud Manager as a template rule, and can then be opted into 
by the cardholder. For example, the Fraud Manager might create a template rule that 
defines how to reject a transaction if the Merchant is not a European merchant. A 
Cardholder might then be asked whether they wanted to 'switch on 1 this rule on their 
card. If they decide to, a new rule is generated for them, based on the template rule. 

• The Cardholder can generate it directly. 

Fraud Manager modifies rule sequence (Fig. 12) 

The order of execution within each set of rules (system, product and cardholder) can be 
modified by the Fraud Manager as required. 

Fraud Manager views cardholder rules (Fig. 13) 

The Fraud Manager can view but not modify Cardholder rules. A "PAN", is the industry 
term for a credit card number ("Primary Account Number"). 

Fraud Manager reviews fraud queue and acknowledges an item (Fig. 14) 
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A fraud queue is a queue of issues that Fraud Managers go through on a regular basis. 
These issues are those items that have matched rules whose action was 'Advise Fraud 
Manager' or 'Decline'. Each item on the fraud queue has to be acknowledged by a Fraud 
Manager. Several different Fraud Managers can be looking at the fraud queue and 
5 acknowledging items at the same time. 

Fraud Manager requests report (Fig. 15) 

The Fraud Manager can get various reports from the system 4. These can relate to fraud 
queue, activated rules, tracked rules, active rules, and suspended rules. 

10 

Fraud Manager sets up system options (Fig. 16) 

There are various system settings that the Fraud Manager needs to set up. These settings 
are global, i.e. in that they apply to all products. 

• Monitor only without declining 

15 • Archival Options - when to archive and how old items must be before they are 
archived. 

Figs. 16 and 17 illustrate how a cardholder can interact with the system. The Cardholders 
can enter rules themselves. One way that they can do this is by choosing to have a 
20 particular rule from a template enabled. The list of templates available to a Cardholder 
whose payment card is part of a particular product might be: 

• Deny Access Outside Ireland 

• Deny Access Outside Europe 

• Deny Access Outside Europe and US 
25 • Deny Access to Internet Merchants 

• Deny All Transactions unless Specified 

• Deny All Internet Transactions unless Specified 

• Allow One-Time Transaction for (£50, £100, £500, £1000) 
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Alternatively, the Cardholder can define a Rule from scratch in the same way that the 
Fraud Manager defines one. 

Cardholder requests list of templates available for credit card number, and adds 
one (Fig. 16) 

The invention provides the interface to the Issuer's online banking system. This interface 
is web-based, although it is not expected that the web interface is delivered directly to the 
Cardholder. Rather, it is expected that the web-based interface is driven by the Issuer's 
computer systems. Here a list of template rules is provided, from which the Cardholder 
can add one or more for their particular credit card. 

Cardholder requests list of current rules for cardholder and can delete one (Fig, 17) 
Referring to Fig. 17, the Cardholder requests a list of current rules available and selects 
the option to delete one. The Cardholder requests the set of rules that are set up for a 
particular PAN. The Cardholder can then optionally delete one of these rules. 

The Cardholder generates a new rule rather than choosing from a list of pre-defined 
template rules and applies this rule to the credit card. 

As shown in Fig. 18 the system supports access by a Customer Service Representative. 
The Issuer's CSR (Customer Service Representative) can perform all functions that a 
Cardholder can perform as well as one other. The same interface is used for CSR 
functions as is provided for Cardholder functions. It is expected that an Issuer's existing 
CSR application will be integrated to allow this extra functionality. 

Referring to Fig. 18, the CSR can see logged activity for a credit card number over a time 
range. The CSR can look into a particular item and see the underlying message if 
available. 

Functional Requirement - allow Auditor to verify integrity of system 



-24- 



The Issuer's auditors - internal and external - must be able to see how and why the 
software functions in the way that it does. The overall functionality of the system is to 
allow Issuers and Cardholders to selectively decline transactions, so the reason for a 
transaction either being declined or not has to be clear to an Auditor. 

Auditor views transaction log (Fig. 19)The Auditor can look into the transaction log to 
see the detail of the processing of the system. 

Auditor examines one particular set of rules in detail (Fig. 20) 

The Auditor can enable rule tracking, which enables the Auditor to track all of the 
decisions relating to a particular rule. When rule tracking is switched on the Auditor will 
see each condition being tested and the result of the test. 

Functional Requirement - allow technical team to control and configure system 
The Technical Operator has' the job of configuring the system for use, and maintaining it 
thereafter. Most of this configuration resides in the database. However, it would be 
inefficient for the processing nodes to have to read their own configuration from the 
database. Instead their configuration is loaded into a local database on each processing 
node. This means that there is a requirement for parts of the database to be loaded into the 
local database on each processing node by the Technical Operator. 

Technical Operator modifies database through web browser (Fig. 21) 

The Technical Operator can modify all tables in the database through a web browser. 

Technical Operator starts/stops processing nodes (Fig. 22) 

The Technical Operator uses an application to allow the starting and stopping of each 
processing node 15. 

Technical Operator sends new configuration to the processing nodes (Fig. 23) 
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The technical operator must instruct the processing nodes to begin using the new registry 
that they have been sent, This is achieved with this use case. 

Technical Operator triggers the processing nodes to begin using a new configuration 
5 (Fig. 24) 

The technical operator must instruct the processing nodes to begin using the new registry 
that they have been sent, This is achieved with this use case. 

O&M node checks status of processing nodes (Fig. 25) 
10 The O&M Node sends a status request message once every 10 seconds to each O&M 
node. The O&M node replies with a response, and on the basis of this, the O&M Node 
database entry is updated. 

Functional Requirement - perform all system maintenance functions automatically 

15 At the end of each period (such as a day), the system 4 must run several procedures 
automatically. 

Database is backed up (Fig. 26) 

The database is backed up to tape on a nighdy basis. 

20 

Database is restored (Fig. 27) 

The data on tape can be restored into the database. 

The system 4 generates a large number of messages and logged items. These objects are 
25 taken out of the database after they have been there for a period of time in order to 
prevent the database from growing too large. Over time, the expired rules (rules that are 
past the end of their stop date) must be archived. Management information (MIS) reports 
are run from a different database server. Entities relevant to MIS reports are copied into a 
separate database. 

30 
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Fraud alarm/ Rejection alarm/ Authorisation confirmation 

This invention allows notifications (SMS/email) that are sent to cardholders to serve 
different functions: 

• They can be configured to act as a 'Fraud Alarm' 
Rules are set within the rule processor to prevent fraud. When a rule infringement 
and possible fraud is detected, a fraud alarm can be triggered and a notification 
sent to the cardholder in order to alert them of possible fraud. 

• They can be configured to act as a 'Rejection Alarm 1 
A notification can be sent to alert the cardholder about a transaction that has been 

- declined for a reason other than the infringement of a rule. For instance, if the 
card management system decides that a particular transaction would push a 
cardholder over their credit limit, it normally does this silently. However, the 
invention can be configured to see this rejection and to send a message to the 
cardholder informing them of the rejection. 

• They can be configured to act as an 'Authorisation Confirmation 1 

20 A notification can be sent to a cardholder whenever a transaction is approved. A* 

cardholder may wish to use this feature to maintain an email log of all 
transactions on a card. 

The invention can be configured to see all approvals and to send a message to the 
25 cardholder informing them of the approval. 

Card Activation 



10 



Much credit card fraud exists in the form of "Mail Fraud". This fraud occurs when a 
30 fraudster intercepts a latter containing a credit card, which is on the way to a cardholder. 
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In order to eliminate this form of fraud, the system 4 can establish rules denying the use 
of each recently issued credit card until an activation event occurs. This activation event 
can have a number of forms: 

• The cardholder goes to an ATM machine and enters the new card followed by the 
5 allocated PIN. A transaction is then sent to the issuing bank from the ATM. This 

transaction is specially formatted to that when the transaction goes through to the 
processor of the invention, the processor deactivates the rule that is denying the card 
use. The card is thus "Activated". 

• Alternatively the cardholder could use his/her computer to access and switch off the 
10 rule that is denying the card's use. The card can be thus activated. 

Online-banking access 

The invention allows rules to be accessed by Cardholders through an online banking 
15 platform. The online banking platform is responsible for construction of credit card 
management web page. The online banking platform calls the verification system in order 
construct the required web page. 

The verification system of the invention provides four services to the online banking 
20 platform to aid it in constructing the card management web page: 

•List all rules that a Cardholder can switch on. 
•Display all rules that a Cardholder can switch off. 
•Switch a rule on. 
25 •Switch a rule off. 

Referring to Fig. 28, a screen of the interface 2 is shown, the screen shown is an example 
of a basic rule activation screen. The customer can access this screen through their online 
banking channel, at an ATM, or through a customer representative. This basic rule 
30 activation is part of the existing renewal or registration process. For example the Issuer 
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may inform the Cardholder that their card will not operate in a specific geographic region 
that may be sensitive to fraud unless the Cardholder informs them to the contrary by 
telephone or online that there are specific countries that they wish to "turn on". 

5 In another application, as shown in Fig. 29, a customer segment uses the verification 
system through the card product they have chosen to use i.e. where the card product has 
predetermined parameters e.g. transaction type or geographic set to Issuer determined 
defaults when the card is issued but changed by the Cardholder to suit their own 
particular requirements whether it is security or control they are concerned about. 

10 

These products are designed for Cardholders who may wish to have more active 
participation in how a card is used, for example, an ancillary card issued by a parent to a 
child where the parent wishes to control how, where and when the card is used by the 
child. Fig. 29 illustrates an example of a parent controlled teenager card and how the 
15 verification system enhances the security and control for the parent. 

The card product design of this particular customer segment would be driven by specific 
customer needs for credit control and security. An example of this would be a corporate 
Card Manager as detailed in Fig. 30. Designed for the corporate market where a financial 
20 controller may wish to centrally control the individual usage profiles of the company's 
payment card base using rules similar to previous examples. Rules could also exclude 
specific merchants or alternatively may allow the card to be used only at specific 
merchants i.e. as a controlled purchasing card. 

25 Transaction rules form an important part of the operation of card management systems by 
card issuers. These are rules that are usually applied at either a system level i.e. a rule 
that will apply to all cards issued by that institution or at a product level i.e. a rule that 
will apply to a particular card product such as a Gold Card. An example of a rule might 
be to deny or refer all transactions from a country that is deemed to be a particular 

30 hotspot for card fraud. 
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It will be appreciated that the invention allows the cardholder to control what happens in 
the authorisation process via the establishment of a rule set that will apply to all 
cardholder's transaction. The cardholder can remotely create, delete or amend rules e.g. 
5 through online banking channels. In addition the invention at the Issuers discretion 
allows for the cardholder to be alerted in real-time of a rule infringement thus alerting 
him to potential misuse of their payment card and allows them to respond automatically 
to this alert in real-time to confirm their authenticity thus allowing the transaction to 
proceed. 

10 

It is expected that the invention will reduce and displace the incidence of fraud in 
payment card networks. It effectively helps manage the risk of card fraud. The system 
can be used as a complementary technology and as such the card Issuers can implement it 
as another line of defence in the fight against fraud. 

15 

The invention is not limited to the embodiments described but may be varied in 
construction and detail. 



